drun: |
~/ Blog The reality of self hosting DNS

Introduction

Self hosting your own DNS resolver is probably the first thing most people do when they start homelabbing, and that's understandable, considering it gets portrayed as the "universal ad-blocker", but the reality is kinda far from it and there are many nuances that need to be addressed

Ad-Blocking

The first issue that not enough people talk about is the way different websites display ads, DNS ad-blocking works for the majority of websites on the internet, as they fetch ads from third party providers, but not for the websites where most people spend the majority of their time (for example social networks or streaming services), all of these websites inject first party ads into the web page, and DNS blocklists cant intercept those.
In addition to this, even blocking ads on apps is often not possible, but your mileage could vary significantly.

Trackers Blocking

On the bright side, tracker blocking is a nice feature of local DNS resolvers, IOT devices and smart TVs collect a ton of data and this behavior can often be intercepted by most blocklists, so devices that can't use a traditional ad-blocker are a good reason to self host your DNS resolver.

DNS rewrites

DNS rewrites are a way to tell your DNS server to redirect all requests to a specific domain, or a wildcard domain, to a specific IP address, this way you don' have to remember the IP addresses and ports of all of your services
This is actually the main reason i host a DNS resolver, and also the main reason why i spent so much time trying to enforce it.

How to enforce your DNS server to your devices

This is the most critical point, DNS over HTTPS (DoH), DNS over TLS (DoT) (, hardcoded DNS and sometimes IPV6 (if not configured correctly) are all things that could make enforcing your local DNS resolver problematic, but there are solutions to fix this.

Disable DNS over HTTPS in your browser of choice

Most browsers ship with Secure DNS enabled, for good reasons, but if you want to take advantage of your own DNS (and hopefully handle the privacy side in another way) you will need to disable this, its straight forward on every desktop browser, the main issue i found is doing this on the android version of Firefox, it seems like it doesn't listen to that for some reason, so i had to switch to a chromium based browser.

Disable "Private DNS" on android

In the phone settings this could potentially force DoH on a system level, so for the same reason as the browser settings it must be disabled.

Redirect traffic to port 53

This is the most impactful part: redirecting all requests on port 53 to your local DNS server, the reason why this is needed is to catch the queries from devices that use a hardcoded DNS, this rule will save you so much time configuring family member smartphones and battling with Google.

Rule type: NAT > Destination NAT

Before looking at the rule its important to understand how the DNS flow works in my home network because its not exactly a typical setup, here's the path DNS queries take from my devices to the upstream resolver: 

    
Devices (53) > Unbound (.1:53) > AdGuard 1 (.1:5353) OR AdGuard 2
(.44:53) > Upstream resolver (853)

(The reason why unbound is before AdGuard in the chain is addressed below in the redundancy section)

  1. IPV6 is completely disabled in my home network, because i still don't understand it well enough, that's why its IPV4 only.

  2. This is used to exclude the backup AdGuard instance from the rule, as it needs to be able to resolve host names of the upstream DoT providers

  3. This is used to match all the traffic that is trying to reach a DNS resolver which is NOT unbound

Note: The firewall itself does NOT need to be excluded from the rule

Reject traffic to port 853

In case some device tries to use DNS over TLS your local DNS or the redirect rule won't intercept it, so its important to make it fall back to regular DNS (unless they decide to go the DoH way, but we do not have a lot of control over that unfortunately).
Queries will then be encrypted when going upstream later if you set your upstream to a TLS address.

Rule type: LAN

  1. This is used to exclude the backup AdGuard IP from the reject rule, so it can resolve upstream

DOH blocklists

From my personal experience these were not very effective, actually, i didn't see it catch a single request in the logs for the time i monitored it, but they could be worth a try, as false positives are rare as well.

Redundancy

How to ensure that if your DNS server goes down you can still browse the Internet?
The solution is either to avoid the redirection rule, and have a cloud DNS provider as secondary, or to host two instances of DNS resolvers on two separate devices.

The way i do this is to host my primary AdGuard instance on OPNsense as a plugin, and the second one on Proxmox in a LXC, and i let Unbound forward queries to both of those, this is the best solution i found for my specific setup, but its definitely not a perfect because:

  • Unbound is a single point of failure, even though it's generally more trustworthy than AdGuard.
  • Queries will show up in AdGuard as they all come from the OPNsense IP

But for a home setup i consider the downsides acceptable.

Another very interesting approach is using a Technitium DNS cluster, but i won't cover that as i didn't try it yet.

Conclusion

Self hosting a DNS resolver is definitely worth it, especially because AdGuard, Pihole and Technitium are all very light and low maintenance, but its important to be realistic on what it can do and what you have to do to make it work as intended.